@concretevitamin I find it hard to actually use config options in a physical operator. Any suggestions?

Merged build triggered.

Merged build started.

@pwendell / @mateiz should we actually build this into Spark directly (i.e. in Aggregator)?

Merged build finished. All automated tests passed.

All automated tests passed.
Refer to this link for build results: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/15952/

@rxin If we are simply trying to read the default values for the params, but not user-set ones (i.e. in the absence of a SQLContext in execute()), I think we could move the default param values to a companion object of SQLConf, and in the assessors of this class, either get the user-set values or else get the default values from the static object.

It would be great to add this into Aggregator as well. Would that replace the implementation here? I.e. does Spark SQL go through Aggregator?

Spark SQL doesn't currently use the aggregator, but we would want to do that.

@mateiz I submitted a patch to core's Aggregator in #1191.

After implementing it in Aggregator, I realized it might be hard for Spark SQL to reuse Aggregator unless we change Aggregator to allocate less temporary objects (or write the aggregation code path in Spark SQL to output key value tuples).